Code changes look good but we can still discuss is this the best solution to fix the problem on showing unnecessary NoneType (and to some extend bool) in Libdoc HTML outputs and specs. Alternative solutions:

• Handle all this on Libdoc side.

• Add bool and perhaps also NoneType from defaults only with RF 3.1. With RF 3.2 there's no need to do that since it gets the real default values and can do automatic conversion based on them.

I think doing something in libdoc side is needed in any case, because PLC is not the only implementation of the dynamic library API (at least I hope so, although it might be the only one currently using the new functionality of the API.)

But I agree that we should change PLC implementation to return defaults differently for 3.1 and 3.2+. From the SeleniumLibrary keywords docs will be generated by using RF 3.2, so from that point of view PLC decisions on RF 3.1 are not significant.

1. For RF 3.2 bool and NoneType hints should not be returned by PLC.
2. PLC should return bool hints with 3.1.
3. PLC could also return NoneType hint in RF 3.1, at least I can not see any real harm on it.

The more I think about this, the better the solution to add both bool and NoneType based on default values to types but only with RF 3.1 feels.

I'm not sure are changes needed on Libdoc side now that dynamic libs can return real default values. It could be argued that if you explicitly return a type from get_keyword_types it should be shown in docs as well. Same as if you explicitly use something like arg: NoneType in a static keyword. Libdoc should probably format argument names, types and default values differently, though, but that's not directly related to this issue.